I highlighted in an earlier blog about the symbiotic relationship between SOA and BPM. I thought I would post a couple of blogs with focus on Business Process Management (BPM). BPM is defined as a strategy for managing and improving the performance of a business through continuous optimization of business processes in a closed-loop cycle of modeling, execution, and measurement. BPM encompasses the discovery, design, and deployment of business processes.
What is a Business Process?
A process describes a sequence or flow of activities in an organization with the= objective of carrying out work. The flow of a process is controlled by decisions, triggers, events, and exceptions, any of which may be influenced by rules or policies.
A process has performance indicators which may be compared to actual performance during execution. The activities in a process are performed by system or human actors (or groups conforming to a role) which may be internal to an organization or external (business partners).
Modeling
BPM relies heavily on models. This is a different paradigm from the requirements analysis, design, implementation, sequence of events of classic software engineering. BPM consists of workflows, business rules,
process models, information flows, and integration, all of which should be represented by the integrated models that constitute the BPM solution.
There are a number of model types that are involved in BPM and that should be closely related or, ideally, fully integrated. These include but are not limited to:
- Business Strategy Models are needed to describe the overall enterprise goals and to provide traceability and justification to the BPM solutions. These include Business Motivation Models (BMM), Balanced Scorecard / Strategy Maps. When a close association to these core business models is maintained a number of potential benefits arise including: traceability of requirements, impact analysis for changes, project justification, and Key Performance Indicators (KPIs) that can be derived to measure effectiveness in association with Business Activity Monitoring (BAM).
- Conceptual Business Process Models are typically used at a high-level to depict a process conceptually without regard for actual implementation. These models are used to communicate and understand the basic conceptual process before modeling lower-level models that depict implementation details.
- Organizational Models: roles are particularly important when human tasks are included in the business process. These can be modeled using techniques defined in OMG Organization Structure Metamodel (currently work-in-progress).
- Business Rules: while the processes provide the procedural flow, the rules (and policies) provide declarative statements of decisions that control the process flow. Rules and policies commonly provide thresholds for service levels, financial approvals, time constraints, etc. A standardized approach for describing rules can be found in OMG Semantics of Business Vocabulary and Business Rules.
- Business Process Diagrams: the core of the BPM modeling activity, typically made up of swim-lanes, tasks, activities, decisions, and routing.
While not always possible, models should be linked to enable traceability from the original business motivation to technical implementation of business process.
Process Types
The terms workflow, task-list, and business process tend to be used interchangeably, but there is a difference between these terms.
Technical Orchestration
Technical orchestration refers to process flows that are typically associated with EAI and MoM. In the case of SOA a number of infrastructure components can also provide this form of orchestration, including the Enterprise Service Bus (ESB).
These flows should be short-lived and stateless, otherwise they may lock important resources causing delays for other users and processes. Simple technical orchestrations may be appropriately maintained within a traditional software component, but more complex flows may benefit from the supervisory control of a process manager. While these technical orchestrations do not contain key business process they may constitute a business activity itself which then becomes a participant in a larger business process.
A simple, but familiar, example of a technical orchestration is an on-line e-commerce shopping cart. A web site provides a simple technical orchestration enabling the user to put items in, change quantities, and finally place an order by navigating to “checkout”. A number of basic technical rules are applied during this flow, such as, validating that the cart has items in it before proceeding to checkout. The technical orchestration and rules seen here were traditionally embedded in applications but, they clearly benefit from a level of abstraction. As with many web applications the process must be stateless to avoid locking shared resources like the product catalog in this scenario. Generally there is little or no business process in an e-commerce shopping cart and the system would not benefit from the full control of a BPM process manager. The cart is a manifestation of a common business activity that might be called “place an order” however, and this is part of a larger business process.
Human Tasks
Many activities (or tasks) must be performed by people rather than computers. These cases arise for various reasons, such as activities requiring research or other intelligent assessment, approval, authorization, or the activity has simply not (yet) been automated. Also, tasks requiring human to human interaction: some tasks will always be performed by a human, such as, providing patient care or conducting an employee performance review meeting.
Human tasks are especially challenging to include in a process automation. Many variables are beyond the control of the BPM system, such as the availability of workers to perform the task, the skill level of the worker is highly subjective, and the work product can rarely be adequately validated by the computer system, to mention just a few.
Business Process
The term business process is often used incorrectly to describe any type of
orchestration, however it is specifically an orchestration of business activities and should not be confused with technical workflow or system processes. Commonly accepted definitions take the following form: a business process is a set of linked activities performed by people and systems that deliver some kind of business value through a product or service to internal or external customers. (At least that what wikipedia stated this week)
A business process or business method is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers. It often can be visualized with a flowchart as a sequence of activities.
Choreography
Choreography describes what occurs between participants in a process. It is a representation of an interaction involving one or more message exchanges between two or more participants. Unlike orchestration, choreography has no central controller, responsible entity, or observer of the process.
A choreography is still a type of process, but differs in purpose and behavior from an orchestration. A regular process, or an orchestration process, defines the flow of activities of a participant or organization. In contrast, choreography formalizes the way business partners coordinate their interactions. The focus is not on orchestrations of the work performed by these participants, but rather on the exchange of information (messages) between them.
Good Luck, Now Go Architect Model
An Enterprise Architect's Musings 